This approach is similar to the type resolving as a result of endpoint matching, in case a proxy endpoint's type is not fully resolved. A difference is that endpoint matching is retried only when a type that is (a dependency of) the endpoint's top-level type gets the resolved state, so a follow-up request will only be sent if there are new dependencies.

In the solution in this PR, a type lookup request is sent each time the condition variable is triggered, which could potentially lead to a large number of requests in case other (non-related) types are resolved when wait_for_type_resolved_impl_locked is waiting for dependencies to become resolved and the condition is triggered. The comment in ddsi_type_get_gpe_matches suggests that resolving dependencies should be triggered from the type lookup reply, which I think will also solve the issue for wait_for_type_resolved_impl_locked.

When handling a reply, we could gather all unresolved dependencies for the types in the reply, and send a request for these types. But what if the request for the type was done explicitly without including deps? We could keep a status requested or requested with deps for a type, but that complicates the administration a bit. And what if an unresolved dependency was already requested, but was not in the reply, should that type be requested again?